Microsoft® introduced cluster-shared volumes (CSV) for high availability applications. A CSV is a shared disk containing a storage volume that is made accessible for read and write operations by all nodes within a failover cluster such as a Windows™ server failover cluster, which is introduced by Microsoft Corporation. This enables a virtual machine (VM) complete mobility throughout the cluster as any node can access the virtual hard disk (VHD) files on the shared volume. CSV simplifies storage management by allowing large numbers of VMs to be accessed off a common shared disk. CSV also increases the resiliency of the cluster by having I/O fault detection and recovery over alternate communication paths between the nodes in the cluster.
While CSV is not required for live migration of VMs, it reduces the potential disconnection period at the end of the migration since the file system does not have to be unmounted/mounted as is the case with a traditional cluster disk. This helps ensure seamless live migration since the physical disk resource does not need to be moved between nodes. CSV increases the chance that a live migration will complete within the TCP reconnect window and ensure a seamless operation to clients.
CSV operates by orchestrating metadata I/O operations between the nodes in the cluster via the server message block protocol. The node with ownership of the LUN orchestrating metadata updates to the storage volume is referred to as the coordinator node. Read and write operations are passed directly to the iSCSI, Fibre Channel, or Fibre Channel over Ethernet shared storage via block based protocols. The cluster will automatically prioritize the most favorable network to route I/O operations by selecting the cluster shared network with the lowest cluster network metric value, Public networks (i.e. networks that connect to users) are assigned higher cluster network metric values by default; this favors I/O operations from using the public network which may already be saturated with user requests.
VSS is a technology included in Microsoft Windows that allows taking manual or automatic backup copies or snapshots of computer files or volumes, even when they are in use. It is implemented as a Windows service called the VSS service. A software VSS provider service is also included as part of Windows to be used by Windows applications. VSS technology requires the file system to be NTFS to be able to create and store shadow copies. Shadow copies can be created on local and external (removable or network) volumes by any Windows component that uses this technology, such as when creating a scheduled Windows backup or automatic system restore point. A snapshot is a read-only point-in-time copy of the volume. Snapshots allow the creation of consistent backups of a volume, ensuring that the contents do not change and are not locked while the backup is being made.
The core component of shadow copy is the VSS service, which initiates and oversees the snapshot creation process. The components that perform all the necessary data transfer are called providers. While Windows comes with a default system provider, software and hardware vendors can create their own software or hardware providers can register them with volume shadow copy service. Each provider has a period of time to complete the snapshot generation.
Other components that are involved in the snapshot creation process are writers. The aim of shadow copy is to create consistent reliable snapshots. But sometimes, this cannot simply be achieved by completing all pending file change operations. Sometimes, it is necessary to complete a series inter-related changes to several related files. For example, when a database application transfers a piece of data from one file to another, it needs to delete it from the source file and create it in the destination file. Hence, a snapshot must not be between the first deletion and the subsequent creation, or else it is worthless; it must either be before the deletion or after the creation. Enforcing this semantic consistency is the duty of writers. Each writer is application-specific and has a period of time to establish a backup-safe state before providers start snapshot creation. If the volume shadow copy service do not receive acknowledgement of success from the corresponding writers with this time-frame, it fails the operation.
A CSV writer reports all application data files present on CSV volumes. Application specific writers, such as Hyper-V™ writers and structured query language (SQL) writers, do not report the data present on a remote node in a high available cluster environment. A CSV writer supports distributed application consistent backups of the whole cluster from a single node. However, restore is not supported in a standard way. There has been a lack of efficient ways to restore the backups of cluster-shared volumes.